支持 10 亿日流量的基础设施：当 Apahce APISIX 遇上腾讯
我们有必要先了解一下 网关 (Gateway) 的作用和价值。
网关是什么
传统架构的通用功能
在传统的架构中，没有网关，那么通用功能该怎么复用起来呢？这里的通用功能指业务无关的一些特性，比如：
安全性：身份验证、授权、防重放、防篡改、对抗 DDoS 等
可靠性：服务降级、熔断、限流等
这些功能在传统架构下，最常见的处理方法就是将其放入服务框架当中，通过 AOP 的方式去实现，类似下图：
模块：
Backend: 后端服务
AOP: 框架携带的 AOP 分层
SD: 服务中心，用于服务间发现，此组件在云原生环境下经常用 Service 替代
LB: 负载均衡器，放置于网络边界上，作为外部流量的入口
这种架构在早些年的设计中非常常见，由此诞生了很多大而全的服务框架，比如 Dubbo, SpringCloud 等。如果我们去认真去研究它们的功能介绍，我们会发现这些功能点它们大多都有。
这种架构的优点在于上下游关系简单，网络传输中也少了一次转发。但是她们的缺点也很明显：
通用功能的迭代会迫使业务服务更新：由于采用的是代码引用，因此需要业务服务重新编译才能使功能生效。对一些没有实现平滑发布的团队，由于服务会中断，因此还得挑业务的空闲期发布。
版本难以管理：由于我们不可能每次发布都让所有业务服务升级最新版，长此以往，各个服务的版本将会不一致。
网关模式的出现
从上图中，我们可以看到传统架构的大部分内容都没有变化，只是在后端服务与 LB（负载均衡器） 之间多出了一个角色：网关。
（这里需要澄清的是，本文讨论的网关特指 ApiGateway ，即针对后台服务以 API 提供服务的场景。）
在上面的这个图中，有时 LB 同时也起到网关的作用，比如 k8s 的 Ingress 组件。
有了网关这个组件后，我们就可以将传统架构的通用功能下沉到网关，这样一来我们获得了很多的好处：
网关可以独立迭代，不再需要业务服务配合
与语言无关，可以配置专门的团队维护
但是网关模式也有自己的缺点：
多了一次转发，延迟变高，排查问题复杂度变高
网关如果不能正常工作，可能会成为整个平台的瓶颈
如何平衡好网关模式的好处和缺点，不仅十分考验业务团队的实力，更是与网关的选型息息相关。接下来，我们要请出本文要介绍的两个重点对象：腾讯 OTeam 和 Apache APISIX。
概念介绍
OTeam
Apache APISIX
感兴趣的同学可以前往 Apache APISIX 的 Github。我们在这里只简单介绍几个点：
Apache APISIX 是基于 OpenResty 的高性能网关，比起竞品 Kong，它的路由性能高了一个数量级
Apache APISIX 使用 ETCD 作为配置存储，可以实现配置秒更新
Apache APISIX 是 Apache 基金会毕业最快、最让导师省心的项目之一
OTeam 的运营策略
大家是不是很好奇腾讯的 OTeam 是怎么运作，又如何和 Github 的社区形成双赢的关系的？
OTeam 的运作参考下图：
上图可以看到 OTeam 的特性迭代是一个完整的闭环：
用户通过 Issue 反馈问题和需求
OTeam 的成员 在 周会 上讨论解决方案，或者直接在 Issue 中跟进
按照解决方案实现特性 or 修复 Bug
代码 Review 后，经历 CI 合入到主干中，再视情况需不需要打包镜像发版
这个流程其实和 Github 多数开源项目的贡献过程是没区别的，关键点在于：
解决了 Issue 后，腾讯工程师会判断这个问题对于社区来说，是否也是一个共性问题。如果是，则会发 PR 到社区的仓库去。 腾讯 OTeam 会定期 Review Apache APISIX 的新特性，判断其是否稳定、是否对腾讯内部也是一个痛点。如果答案是肯定的，合入相关代码。
最早期的时候，OTeam 会每 12 小时，自动合入社区代码到内部仓库中，以保证我们与社区能够共同前进，但这种做法带来了几个问题：
合入的代码通过目前的集成测试只能保证功能 正确性 却没法保证 稳定性，很多偶现的问题都是在并发中发生的。
合入的代码，有时会产生上游的多个 PR 在逻辑上出现冲突的问题，但是各自的 CI 无法检测出来，只有当合入主干后，才会发现主干的代码产生了问题。
出于以上原因，现在 OTeam 转为定期 Review 后合入所需特性的代码的策略。
OTeam 发展情况
截止 2021 年 5 月，Apache APISIX 所在的 OTeam 在腾讯内部已为超过十个团队落地了 Apache APISIX，其中最大的业务日请求量已超过十亿，同时 OTeam 也为 Apache APISIX 开发了超过十个内部特性，其中包括内部的服务发现、RPC 协议转换、打通监控平台等。
与此同时，OTeam 也将开发的一些通用的特性贡献到了社区，为社区带来了不少 Contributor。目前 OTeam 团队中，有两位成员同时也是 ApacheAPISIX 社区的 PMC，OTeam 为社区贡献了超过 50 个 PR。同时，我们相信 OTeam 今后还会与 Apache APISIX 社区开展更多的合作。
内部特性介绍
OTeam 的主要职责是维护 Apache APISIX 的一些针对腾讯内部的特性，那么这些特性都是哪些，又解决了什么样的痛点呢？
内部的痛点
先来看看，有哪些痛点是腾讯内部独有的：
RPC 框架对前端不友好：腾讯内部有很多遗留项目使用了 TARS 框架，它不像 TRPC 一样可以直接支持 http 协议，它只支持 RPC 框架最传统的 tcp 协议，传输内容都使用特定的二进制协议。这带来的一个问题是，我们需要维护一个中间服务来将这些接口转换为前端友好的 http + json 形式。
服务中心多样化：腾讯内部服务发现的组件众多，比如 CL5、L5、北极星……虽然在未来，服务组件会逐渐统一，但在过渡期间，会存在多个服务中心同时使用的情况，最开始的 Apache APISIX 不支持这一点。
告警：作为一个网关解决方案，告警不是一个它应该关注的方向，但是作为网关这个基础组件，告警一定是团队所关心的事项，要怎么解决告警问题，也是一个痛点。
安全性：腾讯这种体量的公司，除了产品本身会面对大量流量之外，产品还有安全性的要求。不乏 ToC 的产品使用了 OTeam ，它们要面对的不止海量用户的误操作，还要面对来自网络的攻击，无论是善意还是恶意的，最典型的有 DDoS、 重放、篡改请求等。这些流量我们是否可以在网关层解决？
问题的解决
网关实现协议转换：OTeam 基于 Apache APISIX 实现了 TRPC 与 TARS 的协议转换，这样一来那些没有实现 http 的遗留服务，可以在网关直接使用封装好的协议转换插件来实现 http 和 rpc 互转的需求而不再需要编写中间服务。
支持多服务中心：这一点其实应该不止腾讯内部需要，相信外面也有很多同学在新老架构的过渡期需要，该特性我们已经反馈给了社区。
指标上报自研监控平台：OTeam 利用插件打通了腾讯内部的几个主要的监控平台，让用户可以简单配置后自动上报接口可观测性的相关信息（链路调用、日志、统计），上报后用户可自行在监控平台配置告警。
防重放与防篡改：OTeam 实现了防重放和防篡改插件，让需要这些能力的对外的业务可以直接开箱即用，保护自己的接口安全。
我们希望这些例子能起到抛砖引玉的作用，鼓励大家去发掘更多 Apache APISIX 的使用场景，更好的把 Apache APISIX 这个好用的工具用起来。比如在腾讯云团队，就有同学利用网关实现了一些腾讯云平台强制要求的 API 规范，将这逻辑下沉到了网关。
最后的话
转眼在腾讯内帮助各个团队维护 Apache APISIX 也一年多了，在这个过程中，OTeam 既帮助业务团队解决了他们的痛点，也不断完善了 Apache APISIX 在腾讯内部的特性，同时也间接推动了社区的发展，真的是一个双赢的事情。
如果读者所在公司如果还没有落地网关的话，可以了解下 Apahce APISIX。已经落地了网关的读者，也希望本文能够给你们带来一点在网关落地上的灵感和帮助。